【早めに準備を！】2020年にAmazon Relational Database Service (RDS)/Amazon AuroraでSSL/TLS証明書をアップデートする必要が生じます

Amazon Relational Database Service (RDS)やAmazon Auroraをお使いの皆さまへお知らせです。2020年3月5日までにCA証明書の更新が必須となります。CA証明書の更新までのスケジュールやコンソール上で証明書の変更手順についてまとめたので、早めに準備を始めましょう！

#Amazon RDS

#Amazon Aurora

#AWS

Shirota

2019.11.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

先日のDevelopers.IO 2019 TOKYOのランチ時に出てきたお弁当の中身が、実質1/2白米という半ライス状態だった事に驚きを隠せませんでした。~~え？半ライスってそういう事じゃなく？~~

▲ でも美味しかった

「うーん……白米とおいなりさんで米がダブってしまった」と脳内で呟いていた、AWS事業本部のShirotaです。ご飯に甘いもの、と聞くとちょっと気後れしてしまいますがおいなりさんは大好きです。

2020年3月5日、RDSで利用しているSSL/TLS証明書が期限を迎えます

さて、見出しの通り 2020年3月5日 、現行のRDSで利用されているSSL/TLS証明書(CA証明書)が期限を迎えます。
現行のCA証明書は rds-ca-2015 となっている筈で、RDSのコンソールの「Connectivity& security」欄から確認できます。
この証明書の期限が切れる為、AWSでは期限を迎える2020年3月5日の1ヶ月前である 2020年2月5日 までに新CA証明書のアップデートによる影響のテストや対応を 強く推奨しています 。
CA証明書を使っていないから関係無い、という事ではありません。
CA証明書は全てのインスタンスに入っているものなので、 SSL/TLS通信を使用している・いないに関わらず CA証明書の更新が必須となります。
AWSが発表しているCA証明書のアップデートについては以下をご覧下さい。

Amazon Relational Database Service (RDS)とAmazon AuroraのSSL/TLS 証明書のアップデートについて

……と、アナウンスについてはこれですませたいのですが、状況が二転三転しており複雑になっております。
一旦、時系列ベースで今後起こり得る可能性のある事を簡単にまとめてみました。

以下のまとめは2019年11月3日現在の情報をまとめたものです。最新の更新情報は公式のアナウンスをご覧下さい。

2020年2月5日: 新CA証明書への強制アップデートについての通知が送付される予定日
2020年2月5日〜3月5日: メンテナンスウィンドウ準拠で新CA証明書へのアップデートが実施される予定。 新CA証明書適用が実施されると短時間のダウンタイムが発生する
2020年3月5日: 現行のCA証明書の利用期限日。現行のCA証明書は利用できなくなり、アップデートがこの日までに実施されていなかった場合は強制アップデートが発生する( ダウンタイム発生 )。新しいCA証明書を持っていないアプリケーションはこの日以降SSL/TLS通信が不可能になる

上記の公式からのアナウンスから引用すると、

次回メンテナンスウィンドウでの実行、もしくは即時での実行をご選択いただけます。

との事なので、2020年2月5日以降メンテナンスウィンドウに来たアップデートのタイミングは延期する事も可能そうにとれます。
ですがどちらにせよ2020年3月5日には強制的にアップデートが発生する為、想定外のタイミングでアップデートが発生してアプリケーションがSSL/TLS通信できなくなる事を防ぐ為には事前に検証を済ませておき、メンテナンスウィンドウを利用して、認知しているタイミングでアップデートを実施する事がベストかと思われます。

手動でCA証明書を更新してみた/クライアントからアクセスしてみた

実際に、CA証明書の更新と、更新したDBインスタンスに対してクライアントからのアクセスをやってみました。

やった事

コンソールでCA証明書の即時更新・ダウンタイムの検証
クライアントからのSSL/TSL通信の検証

検証環境

DBエンジン: MySQL5.6
RDSはSingle-AZ・Multi-AZ、Auroraは1Writer+1Readerのクラスターでそれぞれ検証
インスタンスサイズ
- RDS: db.t2.micro
- Aurora: db.t2.small

CA証明書を即時更新する手順

基本的に、コンソール上での手順はRDS・Aurora共にほぼ共通となっています。

まずは、CA証明書を更新したいDBインスタンスの「Modify」をクリックして、「Network & Security」の項目を探します。
その項目でCA証明書が選択できるようになっているので、今回は新しいCA証明書である「rds-ca-2019」を選択します。

▲ 現行と新しい証明書が選択できるようになっている

ちなみに、新しいCA証明書を選択すると、「クライアントの証明書も更新が必要になるよ」と教えてくれます。しかも 証明書をダウンロードできるリンクまで教えてくれます 。親切。

▲ こんな感じで教えてくれる

RDSとAuroraではリンク先が違うのですが、どちらでもダウンロードする証明書が変わらないかつほぼほぼリンク先の内容が同じでした。一応、両方ともリンクを貼っておきます。(上がRDS、下がAurora)

SSL/TLS を使用した DB インスタンスへの接続の暗号化
 SSL/TLS を使用した DB クラスターへの接続の暗号化

新しいCA証明書を選択したら、そのまま「Continue」して先に進みます。

すると、以下のように変更箇所と変更をいつ実施するかを確認されます。
今回は、即時反映してダウンタイムを検証したいので「Apply immediatery」を選択しました。

▲ 即時反映を選択するとダウンタイムの注意が出るが、今回はそれが検証したい

後は、変更を反映させるだけ。「Modify DB Instance」をクリックして手順自体は完了です。

▲ 無事CA証明書が更新されました！

それぞれの環境におけるダウンタイム

実際にCA証明書の変更を実施して、ダウンタイムを検証してみました。
ダウンタイムに関しては、データベースの使用状況によって変化してくると思われますので、検証を推奨致します。

RDS(Single AZ)

▲ 停止から再起動までは僅か11秒

その後、RDSにアクセスしながら検証したところ、4〜5秒のダウンタイムが生じました。

RDS(Multi AZ)

▲ フェイルオーバーも特に発生せず、11秒

その後、RDSにアクセスしながら検証したところ、4〜5秒のダウンタイムが生じました。
また、強制フェイルオーバーを発生させてみてセカンダリAZにあったDBインスタンスにも新しいCA証明書が適用されている事を確認しました。プライマリとセカンダリ、同時に更新がされているのが分かります。

Aurora(1Writer+1Reader)

Readerノードのログは以下のようになってました。

▲ 停止から再起動が5秒！

その後、RDSにアクセスしながら検証したところ、1〜2秒のダウンタイムが生じました。

Writerノードのログは以下のようになってました。

▲ こっちは僅か2秒！

その後、RDSにアクセスしながら検証したところ、4〜5秒のダウンタイムが生じました。

注意点

主にAuroraでCA証明書を変更する際の注意点になります。

Auroraではインスタンス単位でのCA証明書更新が必要になる

Auroraは、クラスター単位でのCA証明書の変更ができないため、インスタンスごとにCA証明書変更を実施する必要があります。

AuroraでWriterノードからCA証明書の更新を実施するとダウンタイムが長くなる可能性がある

WriterノードからCA証明書変更を試した際、Readerノード側で再起動が発生しました。
具体的には、Writerノードのダウンタイムが4〜5秒ほど生じた後、Readerノード側も4〜5秒のダウンタイムが発生しました。これは自動で発生する為、この分ダウンタイムが長くなる可能性があります。
この為、 リードレプリカ側からCA証明書の変更を実施するとダウンタイムが減らせる可能性が高いです 。

クライアントから接続してみる

EC2にMySQLのクライアントを入れ、証明書を前述のAWS公式ガイドのページからダウンロードしておきます。

まずは、CA証明書をrds-ca-2019に更新したDBインスタンスに、CA-2019のルート証明書を用いてアクセスしてみます。

  
$ mysql -h XXXXXXXXXXXXXX.XXXXXXXX.ap-northeast-1.rds.amazonaws.com --ssl-ca=/home/ec2-user/rds-ca-2019-root.pem --ssl-verify-server-cert -P 3306 -u ユーザー名 -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 20
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]>

無事SSL/TLS接続を用いてアクセスができました。
次に、以前のルート証明書(CA-2015)を用いてアクセスを試みます。

  
$ mysql -h XXXXXXXXXXXXXX.XXXXXXXX.ap-northeast-1.rds.amazonaws.com --ssl-ca=/home/ec2-user/rds-ca-2015-root.pem --ssl-verify-server-cert -P 3306 -u ユーザー名 -p
Enter password:
ERROR 2026 (HY000): SSL connection error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

接続できなくなっているのが分かります。2020年3月5日以降、クライアント側の証明書を更新していないとこのようなエラーが発生する事になるのが分かります。

ちなみに中間証明書とルート証明書の両方を含む証明書バンドルを利用した場合は、 rds-ca-2015のDBインスタンスでもrds-ca-2019のDBインスタンスでもSSL/TLS接続を用いてアクセスできる ことを確認しました。

CA証明書の最終利用期限は延びないので、早めの準備を！

本来は、11月1日以降にDBインスタンスを立てると新しいCA証明書がデフォルトで使用されるようになる予定でしが延期となりました。
このように、適用までのスケジュールは変更が生じる可能性がありますが CA証明書自体の最終利用期限は延びません。
今後何の変更が生じても、これだけは延期になる事が無いと言い切れます。
今から確認しておいた方が良い、と言っても過言ではないと思います。

なるべく早めに 、新しいCA証明書の検証を実施しておきましょう！